我們到底要看什麼，才能說 Vue 真的變好了？

同一份 Lab、同樣的資料量、同樣的操作、同樣的環境，如果其中一個 Benchmark 變快，真的代表使用者的感覺嗎？

假設今天跑完測試，得到 Execution Time 從 300 ms → 260 ms，整整下降 13%，這組數據看起來很漂亮！

但是如果使用者實際操作時，畫面依然會停頓一秒，那這 40ms 的改善，對使用者來說可能根本沒有意義。

反過來也一樣；如果 FPS 從 59 → 58，看起來反而退步了，但原本操作時會出現明顯卡頓，現在卡頓消失了，那到底算不算改善？

當然算。

這段敘述或許很敘述，但有沒有很像跟 PM 溝通的內容，所以我們要找「可以支持結論的 Evidence」，不是在比大小！

先把「Runtime」拆開看

Vue Runtime 的成本，其實不是一個數字，因為一次操作發生時，可能同時經過：

User Interaction
       │
       ▼
┌───────────────┐
│ Reactive      │
│ Update        │
└───────┬───────┘
        ▼
┌───────────────┐
│ Component     │
│ Render        │
└───────┬───────┘
        ▼
┌───────────────┐
│ Vue Patch     │
└───────┬───────┘
        ▼
┌───────────────┐
│ DOM / Browser │
└───────────────┘

所以如果最後只看 FPS，我們其實只看到了最外層的結果，就不會知道到底是哪一層花掉了時間？

這就是 Evidence Matrix 存在的原因。

Evidence 不是「越多越好」

人類在做選擇的時候，很容易陷入一個陷阱，我全部都要！

FPS、Memory、Heap、Render Count、DOM、CPU、Flame Chart 全都看全都要，不是不行，問題是得到一大堆數字，這樣就知道答案了嗎？

所以這次我反過來問 AI 每一個 Evidence，到底要回答什麼問題，以下是得到回饋後濃縮成這幾層：

每個指標都有自己可以回答的方向，所以數字下降可以開心，但是最重要的是 透過不同的 Evidence 知道成本到底發生在哪裡？

真正重要的，是「定位成本」

假設今天看到 FPS ↓，直接說 Vue 變慢了？

或許是 JS 執行時間增加、Frame 超時，所以 FPS 下降；也可能是 JS 很快 DOM 大量更新，Browser Layout / Paint 很慢，造成 FPS 下降。

兩種情況，工程上的解法完全不同，但是成就的結果是一樣的！

這也是這次想寫這個系列很重要的一個轉捩點，不只測「結果」，還要追「成本發生在哪裡」。

Evidence Matrix 就從這裡開始

有了這個判斷方式之後，我們需要一張 Matrix 實驗紀錄表，不是單純拿來「記錄數據」，而是讓每一個 Lab 都回答同樣幾個問題：

① 我們正在解決什麼 Pain？
            ↓
② 怎麼把 Pain 重現出來？
            ↓
③ 要看哪些 Evidence？
            ↓
④ 成本到底發生在哪一層？
            ↓
⑤ Vue 3.6 有沒有真的改變它？
            ↓
⑥ 如果沒有，工程上該怎麼處理？

有方向後，規劃這張 Matrix 最後不需要塞滿所有測量資料，它只需要幫我們維持一個共同的研究視角：

這樣規劃，Matrix 就不是單純的一張「數據表」，反而更像是整個 Lab 的判斷地圖。

萬一結果不好呢？

做到這一步，我發現一件很有意思也有點擔心的事情，如果 Vue 3.6 沒有解決某個 Pain，是不是就代表這個問題無解？

不一定！

說真的！人類對於未知總是會有期待也有恐懼，我是人也會有一樣的擔憂萬一結果不好呢？

所以跟 AI 事前溝通規劃來回好多次，加上它給好多資料舉證，最後我們達成共識：有些成本，本來就不是 Framework 能解決的。

例如：

大量 Component
       ↓
大量 Reactive Dependency
       ↓
大量 Render
       ↓
Browser Rendering 成本

Framework 可以改善其中某一段，但 Application Architecture 仍然可能決定 到底要讓多少東西一起動。

這也讓今年的研究開始出現另一條線：

                 Runtime Pain
                      │
          ┌───────────┴───────────┐
          ▼                       ▼
   Framework 可以改善       Application 要負責
          │                       │
   Runtime / Compiler        Component Boundary
   Rendering Engine          Reactive Boundary
   Scheduling                Composable Boundary
                              Design Boundary

紀錄表的最後一欄原來規劃寫 Vue 怎麼解決？改成 「如果 Framework 沒有解決，我們還能做什麼？」

這張 Matrix，會一路陪我們到最後一天

從明天開始，把 Runtime Pain 放進 Lab，每完成一個 Scenario，就回來問一次：

Pain
 ↓
Evidence
 ↓
Attribution
 ↓
Validation
 ↓
Engineering Decision

最後我們真正想得到的，不是一張「Vue 3.6 Benchmark 排名表」，而是三個答案：

1. Vue 3.6 到底改善了哪些 Runtime Pain？
2. 哪些 Pain 仍然屬於 Application Architecture？
3. AI Coding 時代，我們應該如何設計 Boundary，避免這些 Pain 再次被放大？

準備好了，東風起該下實驗了！

參考資料

• Render Pipeline (https://vuejs.org/guide/extras/rendering-mechanism.html#render-pipeline)
• Vuejs 性能優化 (https://zh-hk.vuejs.org/guide/best-practices/performance#virtualize-large-lists)
• 如何監控網頁的卡頓？ | marketer (https://hypergrowths.com/software-engineering/front-end-dev/14019/topic-39292837/)